Skip to content

Use RESOLVE_NO_SYMLINKS on Linux when following symlinks is disabled #383

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

Use RESOLVE_NO_SYMLINKS on Linux when following symlinks is disabled #383

wants to merge 1 commit into from

Conversation

gitstashpop
Copy link

This addresses a bug where a forward slash is the last element of a symlink directory path and open_dir_nofollow is used.

If a symlink is created to a directory without specifying an absolute path, then the path behind the symlink does not error when opened with open_dir_nofollow.

Take these two symlinks:

> ls -l /home/ylk/test-dir-symlink*
lrwxrwxrwx 1 ylk ylk 24 Feb 19 21:15 /home/ylk/test-dir-symlink ->
/local/home/ylk/test-dir/
lrwxrwxrwx 1 ylk ylk 8 Feb 19 21:27 /home/ylk/test-dir-symlink2 ->
test-dir/

Without this patch, the following behavior is observed when using open_dir_nofollow:

test-dir-symlink/ -> error
test-dir-symlink -> error
test-dir-symlink2 -> error
test-dir-symlink2/ -> no error

@gitstashpop
Use RESOLVE_NO_SYMLINKS on Linux when following symlinks is disabled
39dde67 
This addresses a bug where a forward slash is the last element of a
symlink directory path and `open_dir_nofollow` is used.

If a symlink is created to a directory without specifying an absolute
path, then the path behind the symlink does not error when opened
with `open_dir_nofollow`.

Take these two symlinks:

```
> ls -l /home/ylk/test-dir-symlink*
lrwxrwxrwx 1 ylk ylk 24 Feb 19 21:15 /home/ylk/test-dir-symlink ->
/local/home/ylk/test-dir/
lrwxrwxrwx 1 ylk ylk 8 Feb 19 21:27 /home/ylk/test-dir-symlink2 ->
test-dir/
```

Without this patch, the following behavior is observed when using
open_dir_nofollow:

test-dir-symlink/ -> error
test-dir-symlink -> error
test-dir-symlink2 -> error
test-dir-symlink2/ -> **no error**
@gitstashpop
Copy link
Author

@sunfishcode hope to get some feedback here if this is worse pursuing from your point of view. If yes, I'll fix the failing CI tests

@sunfishcode
Copy link
Member

sunfishcode commented Mar 21, 2025 •
edited
Loading

Sorry for the delay here!

A symlink to an absolute path will always cause a failure with cap-std, because cap-std is defined to use RESOLVE_BENEATH semantics, rather than RESOLVE_IN_ROOT semantics.

O_NOFOLLOW is not the same as RESOLVE_NO_SYMLINKS. O_NOFOLLOW only applies to the last component, while RESOLVE_NO_SYMLINKS disables all symlink resolution. And, when a path ends with /, the / is considered the last component. Consequently, opening test-dir-symlink2 with O_NOFOLLOW follows the symlink and succeeds. This matches the behavior of non-cap-std APIs, where opening test-dir-symlink2/ with O_NOFOLLOW also succeeds.

@sunfishcode
Copy link
Member

As explained in my previous comment, it appears cap-std is working as intended here. If I'm mistaken, please reopen or file a new issue!

@sunfishcode sunfishcode closed this Apr 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@gitstashpop @sunfishcode